src/main/resources/db/migration/V15__create_organization_template.sql (2)

23-26: FK 제약조건에 ON DELETE 동작 명시를 고려하세요.

현재 FK 제약조건에 ON DELETE 절이 없어서 템플릿이 있는 Organization 삭제 시 참조 무결성 오류가 발생합니다. 의도된 동작이라면 괜찮지만, 향후 Organization 삭제 기능 구현 시 ON DELETE CASCADE 또는 ON DELETE RESTRICT를 명시적으로 지정하는 것이 좋습니다.

---

12-21: organization_id 컬럼에 인덱스 추가를 고려하세요.

OrganizationDomainRepository.findAll()에서 organization_id로 그룹핑하는 쿼리가 수행됩니다. 템플릿 수가 증가하면 인덱스가 조회 성능 향상에 도움이 될 수 있습니다.

 create table organization_template
 (
     id              bigint auto_increment,
     name            varchar(255)  not null,
     data            varchar(8191) not null,
     organization_id bigint        not null,
     created_at      timestamp     not null DEFAULT CURRENT_TIMESTAMP,
     modified_at     timestamp     not null DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
-    primary key (id)
+    primary key (id),
+    index idx_organization_template_organization_id (organization_id)
 );

src/main/java/com/debatetimer/entity/organization/OrganizationTemplateEntity.java (1)

27-55: 엔티티–도메인 매핑 전반은 깔끔합니다만, 연관관계 null 제약을 JPA 레벨에도 명시하면 더 좋겠습니다

OrganizationTemplateEntity 의 필드 구성과 toDomain(), getOrganizationId() 설계 모두 도메인 모델과 잘 맞습니다.
다만 조직 연관관계를 확실히 non‑null 로 강제하려면 JPA 매핑에도 제약을 명시하는 편이 의도가 더 분명해집니다.

예를 들어 다음과 같이 수정하는 것을 고려해 볼 수 있습니다:

-    @NotNull
-    @ManyToOne(fetch = FetchType.LAZY)
-    @JoinColumn(name = "organization_id")
+    @NotNull
+    @ManyToOne(fetch = FetchType.LAZY, optional = false)
+    @JoinColumn(name = "organization_id", nullable = false)
     private OrganizationEntity organization;

이렇게 하면 Bean Validation (@NotNull) 뿐 아니라 JPA 매핑과 DDL 측에서도 일관되게 “항상 조직이 존재하는 템플릿”이라는 제약을 표현할 수 있습니다.

src/main/java/com/debatetimer/entity/organization/OrganizationEntity.java (1)

29-47: toDomain 에서 템플릿 리스트를 null 대신 빈 리스트로 정규화하는 것이 안전합니다

현재 OrganizationEntity.toDomain(List<OrganizationTemplate> templates) 가 전달받은 리스트를 그대로 쓰고 있어, 호출 측(예: OrganizationDomainRepository)에서 매핑에 실패하면 templates 가 null 로 넘어올 수 있습니다. 이 경우 도메인 Organization 의 templates 필드도 null 이 되어 이후 사용 시 NPE 위험이 있습니다.

다음처럼 null 을 빈 리스트로 정규화하면 도메인 계층에서 컬렉션을 항상 non‑null 로 다룰 수 있어 더 안전합니다.

-    public Organization toDomain(List<OrganizationTemplate> templates) {
-        return new Organization(this.id, this.name, this.affiliation, this.iconPath, templates);
-    }
+    public Organization toDomain(List<OrganizationTemplate> templates) {
+        List<OrganizationTemplate> safeTemplates = (templates != null) ? templates : List.of();
+        return new Organization(this.id, this.name, this.affiliation, this.iconPath, safeTemplates);
+    }

추가로, affiliation 도 비어 있지 않은 문자열이어야 한다는 도메인 제약이라면 @NotNull 대신 @NotBlank 로 맞추는 것도 검토해볼 만합니다.

src/main/java/com/debatetimer/domainrepository/organization/OrganizationDomainRepository.java (1)

21-35: 로직은 올바르지만 Repository/맵 변수 이름을 역할에 맞게 다듬으면 더 읽기 좋겠습니다

findAll() 구현 자체는 의도대로 잘 동작합니다. 다만 필드·변수명이 실제 담고 있는 타입/역할과 약간 어긋나 가독성이 떨어질 수 있습니다.

• organizationTemplateDomainRepository 필드는 Spring Data OrganizationTemplateRepository 타입이므로, 단순히 organizationTemplateRepository 가 더 직관적입니다.
• idToTemplatesEntity 맵에는 이미 OrganizationTemplateEntity::toDomain 결과(도메인 객체)들이 들어가므로, idToTemplates 정도의 이름이 더 정확합니다.

예를 들면 다음과 같이 정리할 수 있습니다:

-    private final OrganizationTemplateRepository organizationTemplateDomainRepository;
+    private final OrganizationTemplateRepository organizationTemplateRepository;
@@
-        Map<Long, List<OrganizationTemplate>> idToTemplatesEntity = organizationTemplateDomainRepository.findAll()
+        Map<Long, List<OrganizationTemplate>> idToTemplates = organizationTemplateRepository.findAll()
                 .stream()
                 .collect(groupingBy(
                         OrganizationTemplateEntity::getOrganizationId,
-                        mapping(OrganizationTemplateEntity::toDomain, toList()))
-                );
+                        mapping(OrganizationTemplateEntity::toDomain, toList())
+                ));
@@
-        return organizationRepository.findAll()
-                .stream()
-                .map(entity -> entity.toDomain(idToTemplatesEntity.get(entity.getId())))
-                .toList();
+        return organizationRepository.findAll()
+                .stream()
+                .map(entity -> entity.toDomain(idToTemplates.get(entity.getId())))
+                .toList();

OrganizationEntity.toDomain() 에서 null 방어를 추가한다면, 이 메서드는 현재 형태 그대로도 충분히 견고하게 동작할 것 같습니다.

src/test/java/com/debatetimer/fixture/entity/OrganizationTemplateEntityGenerator.java (1)

11-23: 테스트용 템플릿 생성기가 단순·명확하고, 재사용성도 좋습니다

DEFAULT_TEMPLATE_CONTENT 를 상수로 두고 generate(organization, name) 에서 OrganizationTemplateEntity 를 생성·저장하는 흐름이 깔끔합니다. 도메인 리포지토리 테스트에서 읽기 좋은 픽스처 구성이라고 생각됩니다.

다만, 이 긴 문자열이 압축/인코딩된 특정 JSON 이나 템플릿이라면, 나중에 유지보수를 위해 정체를 짧게 주석으로 남기거나 별도 리소스/헬퍼 클래스로 분리해 두는 것도 고려해볼 수 있습니다 (필수는 아니고 선택 사항입니다).

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro